Runtime adaptation in dynamic workspaces

ABSTRACT

The disclosure generally describes computer-implemented methods, software, and systems for search-, context-, and rule-based creation and runtime adaptation in dynamic workspaces. One computer-implemented method includes receiving an access request for an enterprise workspace from a requestor, determining properties of the requestor, determining at least one rule associated with the requestor, determining a context of the determined requestor, generating, by operation of at least one computer, the requested enterprise workspace, and modifying the generated enterprise workspace by executing the determined at least one rule for the determined context.

BACKGROUND

An enterprise workspace provides a flexible, intuitive environment forsingle users and/or teams or groups of users to create, integrate,organize, compose, modify, and delete, through the use of contentmodules, both structured and unstructured content on customizablepersonal or shared pages within the enterprise workspace. Pages may beassigned a permission/role policy that determines what content each usermay see and interact with on a page depending upon a permission/roleassigned to the user. The use of enterprise workspace pages may beresisted by organizations due to their static nature and administrativetime necessary to perform updates to pages in light of multiple possiblepermissions/roles that may apply to users. This lack of agility affectsthe organizations' ability to quickly make changes to an enterpriseworkspace system and an overall agility to adapt to changing business orother conditions. As a result the organizations may seek alternativesolutions to enterprise workspaces.

SUMMARY

The present disclosure relates to computer-implemented methods,software, and systems for search-, context-, and rule-based creation andruntime adaptation in dynamic workspaces. One computer-implementedmethod includes receiving an access request for an enterprise workspacefrom a requestor, determining properties of the requestor, determiningat least one rule associated with the requestor, determining a contextof the determined requestor, generating, by operation of at least onecomputer, the requested enterprise workspace, and modifying thegenerated enterprise workspace by executing the determined at least onerule for the determined context.

Other implementations of this aspect include corresponding computersystems, apparatus, and computer programs recorded on one or morecomputer storage devices, each configured to perform the actions of themethods. A system of one or more computers can be configured to performparticular operations or actions by virtue of having software, firmware,hardware, or a combination of software, firmware, or hardware installedon the system that in operation causes or causes the system to performthe actions. One or more computer programs can be configured to performparticular operations or actions by virtue of including instructionsthat, when executed by data processing apparatus, cause the apparatus toperform the actions.

The foregoing and other implementations can each optionally include oneor more of the following features, alone or in combination:

In a first aspect, combinable with the general implementation, therequestor is one of a single individual or a plurality of individuals.

In a second aspect, combinable with any of the previous aspects, thedetermination of the properties associated with the requestor is basedupon at least one of a user profile or permissions.

In a third aspect, combinable with any of the previous aspects, thepermissions include role-based permissions and user-profile-basedpermissions.

In a fourth aspect, combinable with any of the previous aspects, thecontext of the determined requestor is determined based upon thedetermined properties of the requestor.

In a fifth aspect, combinable with any of the previous aspects, thegenerated enterprise workspace is not presented to the requestor untilafter the modification of the generated enterprise workspace.

In a sixth aspect, combinable with any of the previous aspects, themodification of the generated workspace includes at least one of addingcontent or deleting content from the generated enterprise workspace.

The subject matter described in this specification can be implemented inparticular implementations so as to realize one or more of the followingadvantages. First, there is no need for static persistence of anenterprise workspace and/or enterprise workspace pages. Second, contenton the enterprise workspace and/or the enterprise workspace pages can bedynamically created and/or changed. In some implementations, thecreation and/or changing of the content may based on contextual searchresults and or defined rules. Other advantages will be apparent to thoseskilled in the art.

The details of one or more implementations of the subject matter of thisspecification are set forth in the accompanying drawings and thedescription below. Other features, aspects, and advantages of thesubject matter will become apparent from the description, the drawings,and the claims.

DESCRIPTION OF DRAWINGS

FIG. 1 is a block diagram illustrating an example system for creatingdynamic workspaces.

FIG. 2 is a block diagram illustrating dynamic workspace generator dataconnections.

FIG. 3 is a flow chart illustrating a method for search- andcontext-based creation in dynamic workspaces.

FIG. 4 is a flow chart illustrating a method for rule-based creation indynamic workspaces.

FIG. 5 is a flow chart illustrating a method for runtime adaptation indynamic workspaces.

Like reference numbers and designations in the various drawings indicatelike elements.

DETAILED DESCRIPTION

The disclosure generally describes computer-implemented methods,software, and systems for search-, context-, and rule-based creation andruntime adaptation in dynamic workspaces.

For the purposes of this disclosure, an enterprise resource portal(ERP), also known as an enterprise information portal (EIP) or acorporate portal, is a framework for integrating information, people,and processes across organizational boundaries. An ERP provides a secureunified access point, often in the form of a web-based user interface,and is designed to aggregate and personalize information throughapplication-specific portals. The ERP is a de-centralized contentcontribution and content management system, which keeps the informationalways updated. With only a web browser, enterprise portal users canbegin work once they have been authenticated in the ERP which offers asingle point of access to information, enterprise applications, andservices both inside and outside an organization. ERPs may presentinformation from diverse sources in a unified and structured way, andprovide additional services, such as dashboards, an internal searchengine, e-mail, news, navigation tools, and various other features. ERPsare often used by enterprises for providing their employees, customers,and possibly additional users with a consistent look and feel, andaccess control and procedures for multiple applications, which otherwisewould have been separate entities altogether.

Enterprise Workspace (EWS) technology leverages existing ERPcapabilities and acts as an “add-on” to ERP technology. For example, EWSuser interface (UI) technology may run on top of existing ERPtechnology. EWS functionality provides a flexible, intuitive environmentfor single EWS users and/or teams or groups of EWS users to create,integrate, organize, compose, modify, and delete, through the use ofmodules, both structured and unstructured content on EWS pages within anEWS. EWS technology allows EWS users to take advantage of a“self-service,” that is a decentralized, approach in assembling contenton EMS pages, often without involvement by an enterprise's informationtechnology group.

FIG. 1 illustrates an example distributed computing system 100.Specifically, the illustrated example distributed computing system 100includes or is communicably coupled with an EWS server 102, a client140, and content provider 160 that communicate across a network 130.

At a high level, the EWS server 102 is an electronic computing deviceoperable to receive, transmit, process, store, or manage data andinformation associated with the example distributed computing system100. The EWS server 102 allows EWS users to compose, modify, delete, anddeploy EWS pages. Through a graphical user interface (GUI), an EWSserver 102 user, for example using a client 140, is provided with anefficient and user-friendly presentation of data provided by orcommunicated within the example distributed computing system 100.

In general, the EWS server 102 is a server that stores a contentprovider manager 108, a dynamic workspace generator 109, a search engine110, and a rule engine 111 where at least a portion of the contentprovider manager 108, the dynamic workspace generator 109, the searchengine 110, and/or the rule engine 111 is executed usingrequests/responses sent from/to a client 140 within and communicablycoupled to the illustrated example distributed computing system 100using network 130. In some implementations, the EWS server 102 may storea plurality of various content provider managers 108, dynamic workspacegenerators 109, search engines 110, and/or rule engines 111. In otherimplementations, the EWS server 102 may be a dedicated server meant tostore and execute only a single content provider manager 108, dynamicworkspace generator 109, search engine 110, and/or rule engine 111. Insome implementations, the EWS server 102 may comprise a web server,where content provider manager 108, the dynamic workspace generator 109,the search engine 110, and/or the rule engine 111 represents one or moreweb-based applications accessed and executed by the client 140 using thenetwork 130 or directly at the EWS server 102 to perform the programmedtasks or operations of the content provider manager 108, the dynamicworkspace generator 109, the search engine 110, and/or the rule engine111.

In some implementations, any or all of the content provider manager 108,the dynamic workspace generator 109, the search engine 110, and/or therule engine 111, and/or other components of the EWS server, bothhardware and/or software, may interface with each other and/or theinterface using an application programming interface (API) 112 and/or aservice layer 113. The API 112 may include specifications for routines,data structures, and object classes. The API 112 may be either computerlanguage independent or dependent and refer to a complete interface, asingle function, or even a set of APIs. The service layer 113 providessoftware services to the example distributed computing system 100. Thefunctionality of the enterprise server 102 may be accessible for allservice consumers via this service layer. Software services, such asprovide reusable, defined business functionalities through a definedinterface. For example, the interface may be software written inextensible markup language (XML) or other suitable language. Whileillustrated as an integrated component of the EWS server 102 in theexample distributed computing system 100, alternative implementationsmay illustrate the service layer 113 as a stand-alone component inrelation to other components of the example distributed computing system100. Moreover, any or all parts of the service layer 113 may beimplemented as child or sub-modules of another software module,enterprise application, or hardware module without departing from thescope of this disclosure.

Specifically, the EWS server 102 is responsible for receivingapplication requests, for example to view, create, or define rules tocreate, for example, dynamic workspaces/pages and/or search for contentto include in the dynamic workspaces/pages, from one or more clientapplications associated with the client 140 of the example distributedcomputing system 100. The EWS server is also responsible for respondingto the received requests by processing said requests in the associatedcontent provider manager 108, dynamic workspace generator 110, searchengine 110, and/or rule engine 111, obtaining content from the EWSserver 102 and/or content provider 160 and sending an appropriateresponse back to the requesting client application. In addition torequests from the client 140, requests may also be sent from internal,external. or third-party users, other automated applications, as well asany other appropriate entities, individuals, systems, or computers.According to one implementation, EWS server 102 may also include or becommunicably coupled with an e-mail server, a web server, a cachingserver, a streaming data server, and/or other suitable server. In otherimplementations, the EWS server 102 and related functionality may beprovided in a cloud-computing environment.

As illustrated in FIG. 1, the EWS server 102 includes an interface 104.Although illustrated as a single interface 104 in FIG. 1, two or moreinterfaces 104 may be used according to particular needs, desires, orparticular implementations of the example distributed computing system100. The interface 104 is used by the EWS server 102 for communicatingwith other systems in a distributed environment—including within theexample distributed computing system 100—connected to the network 130;for example, the client 140, as well as other systems communicablycoupled to the network 130 (not illustrated). Generally, the interface104 comprises logic encoded in software and/or hardware in a suitablecombination and operable to communicate with the network 130. Morespecifically, the interface 104 may comprise software supporting one ormore communication protocols associated with communications such thatthe network 130 or interface's hardware is operable to communicatephysical signals within and outside of the illustrated exampledistributed computing system 100.

As illustrated in FIG. 1, the EWS server 102 includes a processor 106.Although illustrated as a single processor 106 in FIG. 1, two or moreprocessors may be used according to particular needs, desires, orparticular implementations of the example distributed computing system100. Generally, the processor 106 executes instructions and manipulatesdata to perform the operations of the EWS server 102. Specifically, theprocessor 106 executes the functionality required to receive and respondto requests from the client 140 and/or create, integrate, organize,compose, modify, and delete EWS workspaces, pages, content, and/or othersuitable data structures and/or content associated with enterpriseworkspaces.

The EWS server 102 also includes a memory 107 that holds data for theEWS server 102. Although illustrated as a single memory 107 in FIG. 1,two or more memories may be used according to particular needs, desires,or particular implementations of the example distributed computingsystem 100. While memory 107 is illustrated as an integral component ofthe EWS server 102, in alternative implementations, memory 107 can beexternal to the EWS server 102 and/or the example distributed computingsystem 100.

In some implementations, the memory 107 includes an EWS 116, an EWS page117, a module 118, module content 119, a module template 120, a modulegallery 121, a rule 122, and a user property 123. Although illustratedas single components in FIG. 1, two or more EWSs 116, EWS pages 117,modules 118, module content 119, module templates 120, module gallery121, rules 122, and user properties 123 may be used according toparticular needs, desires, or particular implementations of the exampledistributed computing system 100.

The EWS 116 is a central repository of knowledge. EWS 116 generation maybe performed either at design-time or runtime and may be based upon, forexample, EWS 116 properties, an EWS 116 owner profile, EWS 116 viewerproperties, and/or other suitable values. For example, the EWS 116 ownerprofile may include age, address, medical profile, etc. The EWS 116viewer profile may include role, relation to the EWS 116 owner,location, etc. In some implementations, the EWS 116 is associated with acontext. For example, the EWS 116 may be associated with a specificuser, for example a particular heart patient, and a support groupassociated with the heart patient, for example, the patient's doctor,friends and family, etc. The EWS 116 may be either personal or shared.The personal EWS 116 is a private area where a single user can maintainpersonal content on a particular EWS page 117 (described below) notaccessible by other EWS users. A shared EWS 116 is an area wheremultiple EMS users, for example the support group or friends and familyof the heart patient, can access shared EWS pages 117. A shared EWS 116is assigned a role/permission policy and each EWS user may be provided arole and associated permission in the shared EWS 116. Roles may be, forexample, workspace owner, workspace manager, and/or workspace member.Associated permissions may be, for example, the ability to create,rename, and/or delete EWS pages 117 and view/update particular contentassociated with EWS pages 117 and/or specific modules 118 (describedbelow) associated with the EWS pages. In some implementations, EWS usersmay have multiple permission levels/roles. In some implementations,users can also customize the EWS 116 with different layouts, branding,and themes. In some implementations, an EWS 116 instance is created froma reusable EWS template (not illustrated). An EWS template has the sameor similar structure as an EWS 116 and is an EWS associated with atemplate tag but not an actual EWS 116 instance. If a new instance of anEWS 116 is created based on an EWS template, the EWS template is copiedand used as the base for the EWS 116 instance.

The EWS page 117 is a container item defining a layout to structure theposition of one or modules 118. In some implementations, EWS users maycreate, rename, and/or delete EWS pages 117 as well as customize EWSpages 117 with different layouts, branding, and themes. EWS users maydefine one or more EWS pages 117 for each EWS 116. The EWS 116 maycontain, for example, static EWS pages 117, EWS page 117 templates,and/or dynamically generated EWS pages 117. Static pages are defined atdesign time and contain content that does not change while dynamic EWSpages 117 are dynamically created, modified, and/or deleted at runtimeand contain changeable, that is “dynamic” content. In someimplementations, an EWS page 117 instance is created from a reusable EWSpage template (not illustrated) similar to the above-mentioned EWStemplate. An EWS page template has the same or similar structure as anEWS page 117 and in an EWS page associated with a template tag but notan actual EWS page 117 instance. If a new instance of an EWS page 117 iscreated based on an EWS page template, the EWS page template is copiedand used as the base for the EWS page 117 instance.

A module 118 is a content item that runs in a personal or shared EWSpage. Module content 119 may include, for example, applications,reports, dashboards, web content (e.g., audio, video, images, RSS feeds,etc.), and documents either from an enterprise or non-enterprisesystem(s). A module 118 may have abilities to respond to workspaceevents and may have associated back-end data and a property set. Amodule 118 may also parameterized by the EWS user to allow changes tothe back-end data and property set of the module 118 at runtime. In someimplementations, a module 118 instance is created from a reusable moduletemplate 120. In these implementations, an EWS user may use a GUI todrag-and-drop a module template 120 from a module gallery 121, a libraryof available modules templates 120, to an EWS page 117 to create aparticular module 118 instance. In other implementations, methods andactions other than drag-and-drop may be used to add the module template120 to the EWS page 117. An EWS user may edit individual properties ofthe created module 118 instance's property set for the purposes of theEWS page 117. Editing may include defining a module content 119 source,location properties, user permissions/roles that may view the module 118and/or specific module content 119, etc. The EWS user may also add,edit, and/or delete back-end data for the module 118. Backend data mayinclude, for example, a description of the module, creatoridentification, date of creation, or other suitable data. In someimplementations, EWS users may customize EWS pages 117 with differentlayouts, branding, and themes. In some implementations, the EWS usercustomizations of the EWS 116 and/or the EWS page 117 may automaticallyaffect and/or supersede EWS user-defined/edited properties for aparticular module 118 instance. In some implementations,generic/pre-defined modules are available that require little to nomodification by an EWS user before use. In some implementations, the EWS116, EWS 117, and module 118 may be implemented in HTML5 or othersuitable computer language.

The rule 122 may represent criteria, conditions, parameters, variables,algorithms, instructions, constraints, references, queries, and anyother appropriate information to define and enable the batch creation ofEWSs 116 and/or EWS pages 117. A rule-set can define few pages and therules for each page's content. In some implementations, the rules 122can add complete EWS templates, EWS 117 pages, and/or EWS page templatesto an EWS. In some implementations, rules can define what content, thatis modules and specific content associated with the modules, is to beadded to the EWS pages 117 based on a specific context and/or theworkspace owner/manager/member's user properties 123 (described below).For example, the context of a particular EWS page 117 owned by a patientis “medical heart condition” so modules 118 associated with this heartcondition should be used to construct the particular EWS 117 page. Also,the particular EWS page 117 is for EWS users with a role of workspacemember (here friends and family). In this example, only content thatshould be viewable by the workspace members associated with the patientshould be displayed on modules 118. In this example, modules 118 thatare capable of receiving, for example, parameterized input or modules118 that are “workspace aware” are used to construct the EWS page 117.In some implementations, the rule 118 can be processed by the ruleengine 111 (described below). In other implementations the rule 118 canbe processed by any other suitable component of the example distributedcomputing system 100, for example the content provider manager 108. Insome implementations, the rule can be time based. For example, an EWS116 could be dynamically established only during a specific week duringa calendar year in which a conference takes place. In someimplementations, the rule 122 can be stored remotely from and accessedby the EWS server 102 using any suitable storage and/or data accessmethod consistent with this disclosure.

The user property 123 is data associated with an EWS user. User property123 data may include, for example, name, department, position, salary,hire date, a role, system password, contact information, location,locale, and other suitable data. In some implementations, location is adynamic property that could be extracted from a location-enabled device,for example a mobile telephone, computer, etc., and could change whilethe location-enabled device is traveling. In some implementations,locale can be used to define a default language of a consuming device.In some implementations, the system password of the consuming devicecannot be used and/or saved for security reasons. In someimplementations, the user property 123 can be used by the dynamicworkspace generator 109 (described below) to determine content tofilter/display within modules 118 on an EWS page 117 within an EWS 116.In these implementations, the user property 123 can also be used todetermine the ability of the EWS user to view, create, rename, and/ordelete EWS pages 117 and update particular viewable content associatedwith the EWS pages 117 and/or the modules 118.

The content provider manager 108 is any type of application that allowsthe client 140 to request and view content on the client 140 afterobtaining content from the EWS server 102 and/or content provider 160 inresponse to a received request from the client 140. Content provider 160may be, for example, applications and data on the EWS server 102 and/orexternal services, business applications, business application servers,databases, RSS feeds, document servers, web servers, streaming servers,caching servers, or other suitable content sources. In someimplementations, the content provider manager 108 enabling theconsumption content provider content by client 140. In someimplementations, the content provider manager 108 allows connections tovarious content providers 160, queries the content provider 160 withregards to provided content, and enables an EWS user to add the contentto an EWS workspace, EWS workspace page, etc. either manually, through arule, or using a search query.

In some implementations, the content provider manager 108 can usecontent provider manager data (not illustrated) or other above-describedata stored in memory 107 to perform tasks associated with the EWSserver 102 or other components of the example distributed computingsystem 100. Content provider manager data may include any type of dataassociated with and/or used by the content provider manager 108,including content provider locations, addresses, storage specifications,content lists, access requirements, or other suitable data. For example,for a database content provider 160, the content provider manager datamay include the server Internet Protocol (IP) address, Uniform ResourceLocator (URL), access permission requirements, data download speedspecifications, etc. Once a particular content provider manager 108 islaunched, a client 140 may interactively process a task, event, or otherinformation associated with EWS server 102. The content provider manager108 can also be any application, program, module, process, or othersoftware that may execute, change, delete, generate, or otherwise manageinformation associated with a particular client 140, and in some cases,a business process (not illustrated) performing and executing businessprocess-related events on the EWS server 102 and/or the client 140. Inparticular, business processes communicate with other clients 140,applications, systems, and components to send and receive events.Additionally, a particular content provider manager 108 may operate inresponse to and in connection with at least one request received fromother content provider managers 108, including a content providermanager 108 associated with another EWS server 102. In someimplementations, the content provider manager 108 can be and/or includea web browser. In some implementations, each content provider manager108 can represent a network-based application accessed and executedusing the network 130 (e.g., through the Internet, or using at least onecloud-based service associated with the content provider manager 108).For example, a portion of a particular content provider manager 108 maybe a Web service associated with the content provider manager 108 thatis remotely called, while another portion of the content providermanager 108 may be an interface object or agent bundled for processingat a remote client 140. Moreover, any or all of a particular contentprovider manager 108 may be a child or sub-module of another softwaremodule or enterprise application (not illustrated) without departingfrom the scope of this disclosure. Still further, portions of theparticular content provider manager 108 may be executed or accessed by auser working directly at the EWS server 102, as well as remotely at acorresponding client 140. In some implementations, the EWS server 102can execute the content provider manager 108.

The dynamic workspace generator 109 is a software and/or hardware engineproviding functionality to dynamically create, modify, and/or deleteEWSs 116, EWS pages 117, and/or modules 118. Runtime EWS 116 generationis performed by the dynamic workspace generator 109. At runtime, an EWS116 structure, that is EWS pages 117/content layout, and/or modules 118,may not be fully defined. EWS 116 generation with an EWS 116 containingdynamic content results in, for example, static EWS pages 117 (ifapplicable), and EWS page templates (not illustrated), and/ordynamically generated EWS pages 117. In some implementations, thedynamic workspace generator 109 can work in conjunction with the ruleengine 111 to perform its functionality, for example in implementingexamples presented below with respect to the rule engine 111. In someimplementations, the dynamic workspace generator 109 can also take intoaccount user properties 123 to determine whether an EWS 116, EWS page117, and/or module 118 is created, modified, and/or deleted. In someimplementations, the dynamic workspace generator 109 can also determinewhether an EWS 116, EWS page 117, and/or module 118 is not visible, thatis filtered, for a particular user based upon the user's user properties123 or other suitable value.

In some implementations, the dynamic workspace generator 109 isweb-based and runs in a client 140 browser window. In someimplementations, the dynamic workspace generator 109 may be partially orcompletely provided in a cloud-computing environment. In someimplementations, a particular dynamic workspace generator 109 canoperate in response to and in connection with at least one requestreceived from a content provider manager 108, search engine 110, and/orrule engine 111. Additionally, a dynamic workspace generator 109 mayoperate in response to and in connection with at least one requestreceived from another dynamic workspace generator 109, content providermanager 108, and/or search engine 110, including those associated withanother EWS server 102. In some implementations, each dynamic workspacegenerator 109 can represent a web-based application accessed andexecuted using the network 130 (e.g., through the Internet, or using atleast one cloud-based service associated with the dynamic workspacegenerator 109). For example, a portion of a particular dynamic workspacegenerator 109 may be a web service associated with a dynamic workspacegenerator 109 that is remotely called, while another portion of theparticular dynamic workspace generator 109 may be an interface object oragent bundled for processing at a remote client 140. Moreover, any orall of a particular dynamic workspace generator 109 may be a child orsub-module of another software module or enterprise application (notillustrated) without departing from the scope of this disclosure. Stillfurther, portions of the particular dynamic workspace generator 109 maybe executed or accessed by an EWS user working directly at the EWSserver 102, as well as remotely at a corresponding client 140.

The search engine 110 is any software and/or hardware computing deviceoperable to receive, transmit, process, and store any appropriate dataassociated with the example distributed computing system 100 of FIG. 1and to perform searching for data related to a search request receivedfrom, or any component of, the EWS server 102 and/or the client 140. Thesearch engine 110 may search data on the EWS server 102, client 140,other enterprise workspace servers 102, other clients 140, and/or otherdata sources external to environment 100 (not illustrated). In someimplementations, each search engine 110 can represent a web-basedapplication accessed and executed using the network 130 (e.g., throughthe Internet, or using at least one cloud-based service associated withthe search engine 110). For example, a portion of a particular searchengine 110 may be a web service associated with a search engine 110 thatis remotely called, while another portion of the particular searchengine 110 may be an interface object or agent bundled for processing ata remote client 140. Moreover, any or all of a particular search engine110 may be a child or sub-module of another software module orenterprise application (not illustrated) without departing from thescope of this disclosure. Still further, portions of the particularsearch engine 110 may be executed or accessed by an EWS user workingdirectly at the EWS server 102, as well as remotely at a correspondingclient 140. Although illustrated as internal to the EWS server 102, insome implementations, the search engine 110 can be external to andcommunicate with at least the EWS server 102 and/or the client 140 usingthe network 130.

Turning now to FIG. 2, FIG. 2 is a block diagram 200 illustratingdynamic workspace generator 109 data connections. For example, followinga performed search using search engine 110, the dynamic workspacegenerator 109, using the search results, would have access to dataassociated with the search results, for example external data 202 a,database data 202 b, and/or enterprise content management (ECM) data 202c. The illustrated circular relationships between the external data 202a, database data 202 b, and ECM data 202 c indicates that the dynamicworkspace generator 109 may create, modify, and/or delete data associatewith each appropriate component and vice versa. The dynamic workspacegenerator 109 may use the accessible data to configure, for example,content for modules 118, EWS pages 117, and/or an EWS 116. In someimplementations, the dynamic workspace generator 109 can have access toa data dictionary (not illustrated); a central, non-redundant, logicaldescription/definition of all data objects used within the exampledistributed computing system 100. Example data objects include databasetables, views, types, domains, search helps, and lock objects. In someimplementations, the dynamic workspace generator 109 can haveconnections to any suitable data source. In some implementations, thesearch engine 110 can have fewer, the same, and/or more data connectionsthan the dynamic workspace generator 109. In some implementations, thedynamic workspace generator 109 can have fewer, the same, and/or moredata connections than the search engine 110.

Returning to FIG. 1, the rule engine 111 can be any application,program, module, process, or other software that may provide methods toevaluate and/or execute at least one rule 122 to define and enable thebatch creation of EWSs 116, EWS pages 117, modules 118, and/or othersuitable data structures, content, etc. associated with enterpriseworkspaces. In some implementations, the owner of the EWS 116, EWS pages117, and or module 118 or other suitably designated user can define therules 122.

The rule engine 111 also connects existing items, for example modules118 and EWS pages 117. In this example, the rule engine 111 may connectthe modules 118 with EWS pages 117 and/or EWS pages 117 with an EWS 116.In some implementations, the connection may be based upon, for example,a context/subject and/or user properties 123. In some implementations,the rule engine 111 can work in conjunction with the dynamic workspacegenerator 109 to perform its functionality, for example in implementingthe following examples. For example, taking the user properties 123 ofthe owner of a particular EWS 116 and the subject of the EWS 116, here apatient with a medical heart condition, the rule engine 111 may executeone or more rules 122 that, on a first EWS page 117, adds a link to amedical heart organization in a module, inserts the top ten results froma search engine related to healthy heart activities into a module,inserts confidential medical information into a module, insertsemergency medical contact information for doctors in the patient'sgeographic area into another module, and creates a module with articlesrelated to his heart condition. On a second EWS page 117, the ruleengine 111 may create modules with contact information for otherpatients willing to share their information in his geographic area withthe same heart condition. The rule engine 111 may also grant access todefined friends and family to his EWS 117 pages and, using the one ormore rules 123, dynamically filter and/or modify what the friends andfamily may see on the EWS 116. For example, the patient's designated“spouse” and “children” may be able to view all content on the EWS,whereas a designated “friend” may not have access to the module with theinserted confidential medical information and the module would beremoved from the associated EWS page 117 as viewed by the friend. Therule engine 111 might also include pictures of various friends andfamily on the EWS pages 117 to allow friend and family to place a nameto a face as well as modules supporting chat functionality to allow thepatient and friends and family to communicate. In this example, thepatient's primary physician's contact information may also be added onthe EWS 116 “home” EWS page 117 to allow friends and family to contactthe physician if necessary. Another example would be implementing anonline auction site using an EWS and rules 122. A buyer and seller coulddynamically be presented different views of the EWS 116 based upon theiruser properties 123 and the rules 122.

In some implementations, a particular rule engine 111 can operate inresponse to and in connection with at least one request received from acontent provider manager 108, dynamic workspace generator 109, and/orsearch engine 110. Additionally, a particular rule engine 111 mayoperate in response to and in connection with at least one requestreceived from another rule engine 111, content provider manager 108,dynamic workspace generator 109, and/or search engine 110, includingthose associated with another EWS server 102. In some implementations,each rule engine 111 can represent a web-based application accessed andexecuted using the network 130 (e.g., through the Internet, or using atleast one cloud-based service associated with the rule engine 111). Forexample, a portion of a particular rule engine 111 may be a web serviceassociated with a rule engine 111 that is remotely called, while anotherportion of the particular rule engine 111 may be an interface object oragent bundled for processing at a remote client 140. Moreover, any orall of a particular rule engine 111 may be a child or sub-module ofanother software module or enterprise application (not illustrated)without departing from the scope of this disclosure. Still further,portions of the particular rule engine 111 may be executed or accessedby an EWS user working directly at the EWS server 102, as well asremotely at a corresponding client 140.

The client 140 may be any computing device operable to connect to orcommunicate with at least the EWS server 102 using the network 130. Ingeneral, the client 140 comprises a computer operable to receive,transmit, process, and store any appropriate data associated with theexample distributed computing system 100. While FIG. 1 illustratesrepresentative clients 140 a-140 d (collectively the client 140), theclient 140 may take other forms without departing from the scope of thisdisclosure. For example, client 140 is intended to encompass anycomputing device such as a desktop computer, laptop/notebook computer,wireless data port, smart phone, personal data assistant (PDA), tabletcomputing device, one or more processors within these devices, or anyother suitable processing device. The client 140 may include a computerthat includes an input device, such as a keypad, touch screen, or otherdevice that can accept user information, and an output device thatconveys information associated with the operation of the EWS server 102,managed system 160, or the client 140 itself, including digital data,visual information, or a GUI 142, as shown with respect to the client140.

The client 140 further includes a client application 146. The clientapplication 146 is any type of application that allows the client 140 torequest and view content on the client 140. In some implementations, theclient application 146 can be and/or include a web browser. In someimplementations, the client-application 146 can use parameters,metadata, and other information received at launch to access aparticular set of data from the server 102. Once a particular clientapplication 146 is launched, a user may interactively process a task,event, or other information associated with the business suite server102. Further, although illustrated as a single client application 146,the client application 146 may be implemented as multiple clientapplications in the client 140.

The illustrated client 140 further includes an interface 152, aprocessor 144, and a memory 148. The interface 152 is used by the client140 for communicating with other systems in a distributedenvironment—including within the example distributed computing system100—connected to the network 130; for example, the EWS server 102 aswell as other systems communicably coupled to the network 130 (notillustrated). The interface 152 may also be consistent with theabove-described interface 104 of the EWS server 102 or other interfaceswithin the example distributed computing system 100. The processor 144may be consistent with the above-described processor 106 of the EWSserver 102 or other processors within the example distributed computingsystem 100. Specifically, the processor 144 executes instructions andmanipulates data to perform the operations of the client 140, includingthe functionality required to send requests to the EWS server 102 and toreceive and process responses from the EWS server 102. The memory 148may be consistent with the above-described memory 107 of the EWS server102 or other memories within the example distributed computing system100 but storing objects and/or data associated with the purposes of theclient 140.

Further, the representative client 140 a illustrates a GUI 142applicable to the remainder representative clients and the client 140 ingeneral. The GUI 142 provides a visual interface with at least a portionof the example distributed computing system 100. Generally, through theGUI 142, an EWS server 102 user is provided with an efficient anduser-friendly presentation of data provided by or communicated withinthe example distributed computing system 100. In particular, the GUI 142may be used to view and navigate EWS pages served by EWS server 102 aswell as create, integrate, organize, compose, modify, and delete bothstructured and unstructured content on EWS pages within personal and/orshared workspaces.

There may be any number of clients 140 associated with, or external to,the example distributed computing system 100. For example, while theillustrated example distributed computing system 100 includes one client140 communicably coupled to the EWS server 102 using network 130,alternative implementations of the example distributed computing system100 may include any number of clients 140 suitable to the purposes ofthe example distributed computing system 100. Additionally, there mayalso be one or more additional clients 140 external to the illustratedportion of the example distributed computing system 100 that are capableof interacting with the example distributed computing system 100 usingthe network 130. Further, the term “client” and “user” may be usedinterchangeably as appropriate without departing from the scope of thisdisclosure. Moreover, while the client 140 is described in terms ofbeing used by a single user, this disclosure contemplates that manyusers may use one computer, or that one user may use multiple computers.

Example Method for Search- and Context-Based Creation in DynamicWorkspaces

Turning now to FIG. 3, FIG. 3 is a flow chart 300 illustrating a methodfor search- and context-based creation in dynamic workspaces. Forclarity of presentation, the description that follows generallydescribes method 300 in the context of FIGS. 1 and 2. However, it willbe understood that method 300 may be performed, for example, by anyother suitable system, environment, software, and hardware, or acombination of systems, environments, software, and hardware asappropriate. For example, one or more of the EWS server, the client, orother computing device (not illustrated) can be used to execute method300 and obtain any data from the memory of the client, the EWS server,or the other computing device. In some implementations, any of thefollowing steps associated with method 500 can be performed by a dynamicworkspace generator and/or a rule engine.

At 302, results from a search performed by an EWS user using a searchsystem (e.g. the search engine) are received. In some implementations,the EWS user may search multiple data sources concurrently. For example,the EWS user may perform a search of Internet sources (e.g., a wiki,user groups, auction sites, medical information, etc.), databases (e.g.,local conventional databases and/or in-memory databases), ECM systems(e.g., for documents, reports, etc.), and/or other suitable datasources. From 302, method 300 proceeds to 304.

At 304, artifacts in the received results are identified. Artifacts maybe, for example, reports, documents, applications, data objects, and/ordata artifacts such as datasets, business intelligence (BI) cubes,database views, etc. From 304, method 300 proceeds to 306.

At 306, a ranking associated with the identified artifacts isidentified. For example, the ranking of the artifacts may be based on anEWS user's role, permissions, or other suitable properties. If an EWSuser has an owner role for an EWS with a context of a medical supportgroup, documents related to administration of a medical support groupmay be ranked higher than data objects related to a medical condition.For an EWS user with a role of member, returned views of medicalcondition information may be ranked higher than the previously mentionedadministrative documents. From 306, method 300 proceeds to 308.

At 308, each identified data artifact is associated with a modulecategory associated with a module further associated with a modulegallery. A module gallery displays modules that may be associated withan EWS page. Modules may be, for example, a document module, a dataobject module, a data cube module, or a view module, or other suitablemodule. From 308, method 300 proceeds to 310.

At 310, the identified artifacts are injected into a content gallery.The content gallery is a user interface element that presents availablecontent associated with a module that may be selected and added to anEWS page. The content gallery extends what is presented in a modulegallery to include any artifacts as discussed above at 304 as well asother suitable artifacts. In some implementations, a chosen artifact isassociated with and consumed by an appropriate module and/or modules.From 310, method 300 proceeds to 312.

At 312, the categorized artifacts injected into the content gallery arecategorized. For example, if a number of documents were received in thesearch results and categorized as documents, an entry (e.g., an icon,link, etc.) for one or more of the identified document artifacts wouldbe presented in the content gallery associated with the module categoryfor “documents.” The entry for each data artifact would present enoughinformation to allow an EWS user to identify the document subject matterand to make a decision as to whether to select the document. Forexample, the document title might be presented as a selectable link oritem in the content gallery and shown as associated with a documentmodule by indentation, graphical connecting lines, separators, boxes, orother suitable indicator to show association with a module category. Insome implementations, the artifacts may be categorized by more than onevalue, for example, as a type (e.g., document) and from a source (e.g.,a government archive as opposed to a wiki). From 312, method 300proceeds to 314.

At 314, the highest ranked categorized artifacts based upon thedetermined ranking are presented and/or indicated to the EWS user. Forexample, the top ranked artifacts may be highlighted, bolded, rearrangein a list, or other suitable method to present/indicate their higherranking than other artifacts to a user. In some implementations, thehigher-ranking artifacts can be presented in a separate user interface.In some implementations, the other categorized artifacts of a low rankcan remain as an icon in the content gallery or in some other form. Insome implementations, the top ranked artifacts can be materializedautomatically into modules on one or more EWS page(s) within an EWS pagelayout(s). In some implementations, the EWS page layouts can bepredefined for specific categories of artifacts/associated modules thatmay be based upon specific EWS user roles, permissions, or othersuitable value. The EWS user may also select other items from thecontent gallery to add to the EWS page(s). From 314, method 300 proceedsto 316.

At 316, a context is constructed for the EWS and/or EWS page. Thecontext is a set of one or more key-value properties, with an API toset/get properties and an ability to listen to change events. Thecontext enables the concept of global workspace/page variables andinter-module interactions. For example, if the received search resultswere related to support options for patients with a specific medicalheart condition in a particular city, the context of the EWS and/or EWSpage may be constructed to support a social group supporting a patientwith the specific medical heart condition in the particular city orgeographic area. After 316, method 300 stops.

Example Method for Rule-Based Creation in Dynamic Workspaces

Turning now to FIG. 4, FIG. 4 is a flow chart 400 illustrating a methodfor rule-based creation in dynamic workspaces. For clarity ofpresentation, the description that follows generally describes method300 in the context of FIGS. 1 and 2. However, it will be understood thatmethod 400 may be performed, for example, by any other suitable system,environment, software, and hardware, or a combination of systems,environments, software, and hardware as appropriate. For example, one ormore of the EWS server, the client, or other computing device (notillustrated) can be used to execute method 400 and obtain any data fromthe memory of the client, the EWS server, or the other computing device.In some implementations, any of the following steps associated withmethod 400 can be performed by a dynamic workspace generator and/or arule engine.

At 402, a request to access an EWS is received from a requestor. Forexample, for an EWS established to support a heart patient, therequestor may be a registered user of the EWS requesting an EWS page.From 402, method 400 proceeds to 404.

At 404, properties of the requestor are determined. For example, theuser profile and/or other suitable may be accessed and analyzed todetermine the identity, context, etc. of the requestor. In someinstances, the requestor may be a single individual or multipleindividuals. For example, for the heart patient's support EWS, therequestor may be the heart patient's doctor, spouse, immediate family,or friends. From 404, method 400 proceeds to 406.

At 406, one or more rules that apply to the requestor are determinedbased on the determined properties of the requestor. The determined oneor more rules for each requestor may be different. For example, rulesthat determine what EWS content the doctor and the spouse of the heartpatient may view may be different than the determined one or more rulesfor all other family members of the heart patient. From 406, method 400proceeds to 408.

At 408, a context of the requestor is determined. In someimplementations, the context can be determined from the determinedproperties of the requestor. The context could be a person, project,and/or group of people. For example, in the case of the EWS for theheart patient, the determined context of the requestor may be determinedto be “doctor,” “family-spouse,” “family-non-spouse,” or “friend.” From408, method 400 proceeds to 410.

At 410, the EWS is generated. In some implementations, the generated EWSis not displayed to the requestor until after 412 as described below.From 410, method 400 proceeds to 412.

At 412, the determined one or more rules are executed in the determinedcontext to determined appropriate content to display in the requestedEWS. For example, for a requestor with a “family-spouse” context,specific medial status information, diagnosis, doctor medical reports,etc. may be added by the executed rules to an EWS page generated at 410with this information and subsequently displayed to the “family-spouse”requestor. On the other hand, for a requestor(s) with a context of“friend,” the executed rules may remove specific content from the EWSpage generated at 410 due to privacy laws so that a requestor with acontext of “friend” may not view the removed content without specificpermission granted by the heart patient or other authorized individual.In some implementations, the determined rules may include governmentlaws/regulations, for example HIPPA, custom rules, and/or other suitablerules to add and/or filter content in an EWS. In this way, thedetermined rules and/or determined context applicable to therequestor/requestors may be used to add and/or filter content displayedin the EWS. In some implementations, filtered/added content can include,for example, an entire enterprise workspace, one or more EWS pages,specific content on one or more EWS pages, and/or other suitable datastructures and/or content consistent with this disclosure. From 412,method 400 proceeds to 414.

At 414, the context of the EWS is determined. For example, in the caseof the EWS for the heart patient, the determined EWS context could be“Medical Support,” “Multi-user Medical Support,” or the like. After 414,method 400 stops.

Example Method for Runtime Adaptation in Dynamic Workspaces

Turning now to FIG. 5, FIG. 5 is a flow chart 500 illustrating a methodfor runtime adaptation in dynamic workspaces. For clarity ofpresentation, the description that follows generally describes method500 in the context of FIGS. 1 and 2. However, it will be understood thatmethod 500 may be performed, for example, by any other suitable system,environment, software, and hardware, or a combination of systems,environments, software, and hardware as appropriate. For example, one ormore of the EWS server, the client, or other computing device (notillustrated) can be used to execute method 500 and obtain any data fromthe memory of the client, the EWS server, or the other computing device.In some implementations, any of the following steps associated withmethod 500 can be performed by a dynamic workspace generator and/or arule engine.

At 502, a request for an EWS page is received from an EWS user. From502, method 500 proceeds to 504.

At 504, properties associated with the EWS user are determined. Theproperties of the EWS user may include the requestor's role, personalpreferences, location, or other suitable values. From 504, method 500proceeds to 506.

At 506, the EWS user's profile is determined based on the determinedproperties associated with the EWS user. From 506, method 500 proceedsto 508.

At 508, appropriate content to display on the requested EWS page isdetermined based upon the determined properties and/or the user profileassociated with the EWS user. For example, for a particular EWS useraccessing the EWS page, where the EWS user has a role of member and auser profile data value of a “friend” of the EWS owner (e.g., apatient), the EWS user (friend) may not be able to view certain medicalinformation on the page related to the EWS owner (patient). However, thepatient's physician or a particular EWS user designated with a userprofile data value indicating a family relationship may be presumptivelyauthorized to view the medical information. In this way, determinedproperties and an EWS user's profile may be used to filter contentdisplayed on the requested EWS page. In some implementations, filteredcontent can include, for example, an entire enterprise workspace, one ormore EWS pages, specific content on one or more EWS pages, and/or othersuitable data structures and/or content consistent with this disclosure.From 508, method 500 proceeds to 510.

At 510, a determination is made whether any rules and/or permissionsapply to the EWS user. If at 510, it is determined that rules and/orpermissions apply to the EWS user, method 500 proceeds to 512 where thedetermined appropriate content to display on the requested EWS page isfiltered according to applicable rules and/or permissions. For example,for the particular EWS user with an EWS role of member and user profiledata value of “friend” attempting to access the EWS page, associatedrules may specify that unless the member is an authorized viewer undergovernment laws/regulations (e.g., HIPPA), the EWS user is not able toview certain medical information on the page related to the patientassociated with the requested EWS page. However, the patient's physicianor the particular EWS user designated in a user profile as a member ofthe heart patient's family may be authorized to view the medicalinformation only if they are a “family:spouse,” “family:guardian,” etc.As a result, the determined appropriate content is filtered by rulesand/or permissions applicable to the EWS user to only allow appropriatecontent to be displayed to the EWS user. In some implementations,filtered content can include, for example, an entire enterpriseworkspace, one or more EWS pages, specific content on one or more EWSpages, and/or other suitable data structures and/or content consistentwith this disclosure. If at 512, however, it is determined that thatrules and/or permissions do not apply to the EWS user, method 500proceeds to 514.

At 514, the requested EWS page is generated. After 514, method 500stops.

Implementations of the subject matter and the functional operationsdescribed in this specification can be implemented in digital electroniccircuitry, in tangibly-embodied computer software or firmware, incomputer hardware, including the structures disclosed in thisspecification and their structural equivalents, or in combinations ofone or more of them. Implementations of the subject matter described inthis specification can be implemented as one or more computer programs,i.e., one or more modules of computer program instructions encoded on atangible, non-transitory computer-storage medium for execution by, or tocontrol the operation of, data processing apparatus. Alternatively or inaddition, the program instructions can be encoded on anartificially-generated propagated signal, e.g., a machine-generatedelectrical, optical, or electromagnetic signal that is generated toencode information for transmission to suitable receiver apparatus forexecution by a data processing apparatus. The computer-storage mediumcan be a machine-readable storage device, a machine-readable storagesubstrate, a random or serial access memory device, or a combination ofone or more of them.

The term “data processing apparatus” refers to data processing hardwareand encompasses all kinds of apparatus, devices, and machines forprocessing data, including by way of example a programmable processor, acomputer, or multiple processors or computers. The apparatus can also beor further include special purpose logic circuitry, e.g., a centralprocessing unit (CPU), a FPGA (field programmable gate array), or anASIC (application-specific integrated circuit). In some implementations,the data processing apparatus and/or special purpose logic circuitry maybe hardware-based and/or software-based. The apparatus can optionallyinclude code that creates an execution environment for computerprograms, e.g., code that constitutes processor firmware, a protocolstack, a database management system, an operating system, or acombination of one or more of them. The present disclosure contemplatesthe use of data processing apparatuses with or without conventionaloperating systems, for example LINUX, UNIX, WINDOWS, MAC OS, ANDROID,IOS or any other suitable conventional operating system.

A computer program, which may also be referred to or described as aprogram, software, a software application, a module, a software module,a script, or code, can be written in any form of programming language,including compiled or interpreted languages, or declarative orprocedural languages, and it can be deployed in any form, including as astand-alone program or as a module, component, subroutine, or other unitsuitable for use in a computing environment. A computer program may, butneed not, correspond to a file in a file system. A program can be storedin a portion of a file that holds other programs or data, e.g., one ormore scripts stored in a markup language document, in a single filededicated to the program in question, or in multiple coordinated files,e.g., files that store one or more modules, sub-programs, or portions ofcode. A computer program can be deployed to be executed on one computeror on multiple computers that are located at one site or distributedacross multiple sites and interconnected by a communication network.While portions of the programs illustrated in the various figures areshown as individual modules that implement the various features andfunctionality through various objects, methods, or other processes, theprograms may instead include a number of sub-modules, third partyservices, components, libraries, and such, as appropriate. Conversely,the features and functionality of various components can be combinedinto single components as appropriate.

The processes and logic flows described in this specification can beperformed by one or more programmable computers executing one or morecomputer programs to perform functions by operating on input data andgenerating output. The processes and logic flows can also be performedby, and apparatus can also be implemented as, special purpose logiccircuitry, e.g., a CPU, a FPGA, or an ASIC.

Computers suitable for the execution of a computer program include, byway of example, can be based on general or special purposemicroprocessors or both, or any other kind of CPU. Generally, a CPU willreceive instructions and data from a read-only memory (ROM) or a randomaccess memory (RAM) or both. The essential elements of a computer are aCPU for performing or executing instructions and one or more memorydevices for storing instructions and data. Generally, a computer willalso include, or be operatively coupled to receive data from or transferdata to, or both, one or more mass storage devices for storing data,e.g., magnetic, magneto-optical disks, or optical disks. However, acomputer need not have such devices. Moreover, a computer can beembedded in another device, e.g., a mobile telephone, a personal digitalassistant (PDA), a mobile audio or video player, a game console, aglobal positioning system (GPS) receiver, or a portable storage device,e.g., a universal serial bus (USB) flash drive, to name just a few.

Computer-readable media (transitory or non-transitory, as appropriate)suitable for storing computer program instructions and data include allforms of non-volatile memory, media and memory devices, including by wayof example semiconductor memory devices, e.g., erasable programmableread-only memory (EPROM), electrically-erasable programmable read-onlymemory (EEPROM), and flash memory devices; magnetic disks, e.g.,internal hard disks or removable disks; magneto-optical disks; andCD-ROM, DVD+/−R, DVD-RAM, and DVD-ROM disks. The memory may storevarious objects or data, including caches, classes, frameworks,applications, backup data, jobs, web pages, web page templates, databasetables, repositories storing business and/or dynamic information, andany other appropriate information including any parameters, variables,algorithms, instructions, rules, constraints, or references thereto.Additionally, the memory may include any other appropriate data, such aslogs, policies, security or access data, reporting files, as well asothers. The processor and the memory can be supplemented by, orincorporated in, special purpose logic circuitry.

To provide for interaction with a user, implementations of the subjectmatter described in this specification can be implemented on a computerhaving a display device, e.g., a CRT (cathode ray tube), LCD (liquidcrystal display), or plasma monitor, for displaying information to theuser and a keyboard and a pointing device, e.g., a mouse, trackball, ortrackpad by which the user can provide input to the computer. Input mayalso be provided to the computer using a touchscreen, such as a tabletcomputer surface with pressure sensitivity, a multi-touch screen usingcapacitive or electric sensing, or other type of touchscreen. Otherkinds of devices can be used to provide for interaction with a user aswell; for example, feedback provided to the user can be any form ofsensory feedback, e.g., visual feedback, auditory feedback, or tactilefeedback; and input from the user can be received in any form, includingacoustic, speech, or tactile input. In addition, a computer can interactwith a user by sending documents to and receiving documents from adevice that is used by the user; for example, by sending web pages to aweb browser on a user's client device in response to requests receivedfrom the web browser.

The term “graphical user interface,” or GUI, may be used in the singularor the plural to describe one or more graphical user interfaces and eachof the displays of a particular graphical user interface. Therefore, aGUI may represent any graphical user interface, including but notlimited to, a web browser, a touch screen, or a command line interface(CLI) that processes information and efficiently presents theinformation results to the user. In general, a GUI may include aplurality of user interface (UI) elements, some or all associated with aweb browser, such as interactive fields, pull-down lists, and buttonsoperable by the business suite user. These and other UI elements may berelated to or represent the functions of the web browser.

Implementations of the subject matter described in this specificationcan be implemented in a computing system that includes a back-endcomponent, e.g., as a data server, or that includes a middlewarecomponent, e.g., an application server, or that includes a front-endcomponent, e.g., a client computer having a graphical user interface ora Web browser through which a user can interact with an implementationof the subject matter described in this specification, or anycombination of one or more such back-end, middleware, or front-endcomponents. The components of the system can be interconnected by anyform or medium of wireline and/or wireless digital data communication,e.g., a communication network. Examples of communication networksinclude a local area network (LAN), a radio access network (RAN), ametropolitan area network (MAN), a wide area network (WAN), WorldwideInteroperability for Microwave Access (WIMAX), a wireless local areanetwork (WLAN) using, for example, 802.11a/b/g/n and/or 802.20, all or aportion of the Internet, and/or any other communication system orsystems at one or more locations. The network may communicate with, forexample, Internet Protocol (IP) packets, Frame Relay frames,Asynchronous Transfer Mode (ATM) cells, voice, video, data, and/or othersuitable information between network addresses.

The computing system can include clients and servers. A client andserver are generally remote from each other and typically interactthrough a communication network. The relationship of client and serverarises by virtue of computer programs running on the respectivecomputers and having a client-server relationship to each other.

While this specification contains many specific implementation details,these should not be construed as limitations on the scope of anyinvention or on the scope of what may be claimed, but rather asdescriptions of features that may be specific to particularimplementations of particular inventions. Certain features that aredescribed in this specification in the context of separateimplementations can also be implemented in combination in a singleimplementation. Conversely, various features that are described in thecontext of a single implementation can also be implemented in multipleimplementations separately or in any suitable sub-combination. Moreover,although features may be described above as acting in certaincombinations and even initially claimed as such, one or more featuresfrom a claimed combination can in some cases be excised from thecombination, and the claimed combination may be directed to asub-combination or variation of a sub-combination.

Similarly, while operations are depicted in the drawings in a particularorder, this should not be understood as requiring that such operationsbe performed in the particular order shown or in sequential order, orthat all illustrated operations be performed, to achieve desirableresults. In certain circumstances, multitasking and parallel processingmay be advantageous. Moreover, the separation of various system modulesand components in the implementations described above should not beunderstood as requiring such separation in all implementations, and itshould be understood that the described program components and systemscan generally be integrated together in a single software product orpackaged into multiple software products.

Particular implementations of the subject matter have been described.Other implementations, alterations, and permutations of the describedimplementations are within the scope of the following claims as will beapparent to those skilled in the art. For example, the actions recitedin the claims can be performed in a different order and still achievedesirable results.

Accordingly, the above description of example implementations does notdefine or constrain this disclosure. Other changes, substitutions, andalterations are also possible without departing from the spirit andscope of this disclosure.

What is claimed is:
 1. A computer-implemented method, comprising:receiving an access request for an enterprise workspace from arequestor; determining properties of the requestor; determining at leastone rule associated with the requestor; determining a context of thedetermined requestor; generating, by operation of at least one computer,the requested enterprise workspace; and modifying the generatedenterprise workspace by executing the determined at least one rule forthe determined context.
 2. The computer-implemented method of claim 1,wherein the requestor is one of a single individual or a plurality ofindividuals.
 3. The computer-implemented method of claim 1, wherein thedetermination of the properties associated with the requestor is basedupon at least one of a user profile or permissions.
 4. Thecomputer-implemented method of claim 3, wherein the permissions includerole-based permissions and user-profile-based permissions.
 5. Thecomputer implemented method of claim 4, wherein the context of thedetermined requestor is determined based upon the determined propertiesof the requestor.
 6. The computer-implemented method of claim 1, whereinthe generated enterprise workspace is not presented to the requestoruntil after the modification of the generated enterprise workspace. 7.The computer-implemented method of claim 1, wherein the modification ofthe generated workspace includes at least one of adding content ordeleting content from the generated enterprise workspace.
 8. Acomputer-program product, comprising computer-readable instructionsembodied on tangible, non-transitory media, the computer-readableinstructions operable when executed to: receive an access request for anenterprise workspace from a requestor; determine properties of therequestor; determine at least one rule associated with the requestor;determine a context of the determined requestor; generate the requestedenterprise workspace; and modify the generated enterprise workspace byexecuting the determined at least one rule for the determined context.9. The computer-program product of claim 8, wherein the requestor is oneof a single individual or a plurality of individuals.
 10. Thecomputer-program product of claim 8, wherein the determination of theproperties associated with the requestor is based upon at least one of auser profile or permissions.
 11. The computer-program product of claim10, wherein the permissions include role-based permissions anduser-profile-based permissions.
 12. The computer-program product ofclaim 11, wherein the context of the determined requestor is determinedbased upon the determined properties of the requestor.
 13. Thecomputer-program product of claim 8, wherein the generated enterpriseworkspace is not presented to the requestor until after the modificationof the generated enterprise workspace.
 14. The computer-program productof claim 8, wherein the modification of the generated workspace includesat least one of adding content or deleting content from the generatedenterprise workspace.
 15. A system, comprising: memory operable to storeat least an enterprise workspace; and at least one hardware processorinteroperably coupled to the memory and operable to: receive an accessrequest for an enterprise workspace from a requestor; determineproperties of the requestor; determine at least one rule associated withthe requestor; determine a context of the determined requestor; generatethe requested enterprise workspace; and modify the generated enterpriseworkspace by executing the determined at least one rule for thedetermined context.
 16. The system of claim 15, wherein the requestor isone of a single individual or a plurality of individuals.
 17. The systemof claim 15, wherein the determination of the properties associated withthe requestor is based upon at least one of a user profile orpermissions.
 18. The system of claim 17, wherein the permissions includerole-based permissions and user-profile-based permissions.
 19. Thesystem of claim 18, wherein the context of the determined requestor isdetermined based upon the determined properties of the requestor. 20.The system of claim 15, wherein the generated enterprise workspace isnot presented to the requestor until after the modification of thegenerated enterprise workspace.
 21. The system of claim 15, wherein themodification of the generated workspace includes at least one of addingcontent or deleting content from the generated enterprise workspace.